Utilizing a machine learning model to perform actions based on selection of a single selection abort transaction mechanism

ABSTRACT

A device receives, from a transaction device, transaction data associated with a transaction of a user logged into the transaction device, and receives information indicating a selection of an abort transaction mechanism to cause the transaction to be canceled concurrently with the user being logged out of the transaction device. The device provides, to a user device associated with the user, a notification indicating that the transaction was canceled and that the user was logged out, and determines whether a response, indicating that the notification was received by the user and indicating a reason for utilizing the abort transaction mechanism, is received from the user device within a threshold period of time. The device provides an alert message to an emergency point of contact for the user when it is determined that the response is not received from the user device within the threshold period of time.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/842,959, filed Apr. 8, 2020 (now U.S. Pat. No. 11,775,980), which isa continuation of U.S. patent application Ser. No. 16/425,172, filed May29, 2019 (now U.S. Pat. No. 10,628,829), the contents of which areincorporated herein by reference in their entireties.

BACKGROUND

A transaction device may include an automated teller machine (ATM)device, a point of sale (POS) device, a kiosk device, and/or the like. Auser of a transaction device may conduct a variety of transactions viathe transaction device, such as receiving money, depositing money,checking an account balance, and/or the like.

SUMMARY

According to some implementations, a method may include receiving, froma transaction device, transaction data associated with a transaction ofa user logged into the transaction device, where the transaction devicemay include an abort transaction mechanism that, when selected, enablesthe user to concurrently cancel the transaction and log out of thetransaction device. The method may include receiving informationindicating a selection of the abort transaction mechanism from thetransaction device to cause the transaction to be canceled concurrentlywith the user being logged out of the transaction device. The method mayinclude providing, to a user device associated with the user and basedon receiving the information indicating the selection of the aborttransaction mechanism, a notification indicating that the transactionwas canceled and that the user was logged out of the transaction device,and determining whether a response, indicating that the notification wasreceived by the user and indicating a reason for utilizing the aborttransaction mechanism, is received from the user device within athreshold period of time. The method may include providing an alertmessage to an emergency point of contact for the user and/or to anemergency service when it is determined that the response is notreceived from the user device within the threshold period of time.

According to some implementations, a device may include one or morememories, and one or more processors, communicatively coupled to the oneor more memories, to receive, from a transaction device, transactiondata associated with a transaction of a user logged into the transactiondevice, where the transaction device may include an abort transactionmechanism that, when selected a single time, causes the transaction tobe canceled and the user to be logged out of the transaction device. Theone or more processors may receive information indicating a selection ofthe abort transaction mechanism from the transaction device to cause thetransaction to be canceled and the user to be logged out of thetransaction device, and may cause a camera at a location of thetransaction device to be monitored based on receiving the informationindicating the selection of the abort transaction mechanism. The one ormore processors may provide, to a user device associated with the user,a notification indicating that the transaction was canceled and that theuser was logged out of the transaction device, and may determine whethera response to the notification is received from the user device, wherethe response may be to indicate that the notification was received bythe user and indicate a reason for utilizing the abort transactionmechanism. The one or more processors may selectively provide an alertmessage to an emergency point of contact for the user and/or to anemergency service based on whether the response to the notification isreceived from the user device. The alert message may be provided whenthe response is not received from the user device, or the alert messagemay not be provided when the response is received from the user deviceor when camera data from the camera indicates that the user is safe.

According to some implementations, a non-transitory computer-readablemedium may store instructions that include one or more instructionsthat, when executed by one or more processors of a device, cause the oneor more processors to receive, from a transaction device, transactiondata associated with a transaction of a user logged into the transactiondevice, where the transaction device may include an abort transactionmechanism that, when selected, enables the user to cancel thetransaction and log out of the transaction device at a same time. Theone or more instructions may cause the one or more processors to receiveinformation indicating a selection of the abort transaction mechanismfrom the transaction device to cause the transaction to be canceled andthe user being logged out of the transaction device at the same time,and provide, to a user device associated with the user and based onreceiving the information indicating the selection of the aborttransaction mechanism, a notification indicating that the transactionwas canceled and that the user was logged out of the transaction device.The one or more instructions may cause the one or more processors todetermine whether a response to the notification is received from theuser device within a threshold period of time, where the response mayindicate that the notification was received by the user and may indicatea reason for utilizing the abort transaction mechanism. The one or moreinstructions may cause the one or more processors to selectively providean alert message to an emergency point of contact for the user and/or toan emergency service based on whether the response to the notificationis received from the user device within the threshold period of time.The alert message may be provided when the response is not received fromthe user device, or the alert message may not be provided when theresponse is received from the user device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A-1F are diagrams of one or more example implementationsdescribed herein.

FIG. 2 is a diagram of an example environment in which systems and/ormethods described herein may be implemented.

FIG. 3 is a diagram of example components of one or more devices of FIG.2 .

FIGS. 4-6 are flow charts of example processes for utilizing a machinelearning model to perform actions based on selection of a singleselection abort transaction mechanism.

DETAILED DESCRIPTION

The following detailed description of example implementations refers tothe accompanying drawings. The same reference numbers in differentdrawings may identify the same or similar elements.

Sometimes a user of a transaction device feels unsafe when conducting atransaction at the transaction device (e.g., when someone is panhandlingat the transaction device). A user may also feel captive at atransaction device when the user needs to quickly leave the transactiondevice during a transaction (e.g., to catch a train). However, in bothsituations, the user must first cancel the transaction and then must logout of the transaction device to ensure that the transaction is canceledbefore the user leaves the transaction device. The multiple stepsrequired to ensure that the transaction is canceled may endanger thelife of the user and/or may cause the user to be unable to quickly leavethe transaction device (e.g., which may cause the user to miss a train).

Furthermore, the multiple steps waste computing resources (e.g.,processing resources, memory resources, and/or the like) and networkresources associated with performing the multiple steps. For example,the transaction device utilizes computing resources to perform theadditional steps needed to cancel the transaction, the transactiondevice utilizes network resources to communicate with a backend systemand cancel the transaction, the backend system utilizes computingresources to perform the additional steps needed to cancel thetransaction, and/or the like.

Some implementations described herein provide a verification platformthat utilizes a machine learning model to perform actions based onselection of a single selection abort transaction mechanism. Forexample, the verification platform may receive, from a transactiondevice, transaction data associated with a transaction of a user loggedinto the transaction device, where the transaction device may include anabort transaction mechanism that, when selected, enables the user toconcurrently cancel the transaction and log out of the transactiondevice. The verification platform may receive information indicating aselection of the abort transaction mechanism from the transaction deviceto cause the transaction to be canceled concurrently with the user beinglogged out of the transaction device. The verification platform mayprovide, to a user device associated with the user and based onreceiving the information indicating the selection of the aborttransaction mechanism, a notification indicating that the transactionwas canceled and that the user was logged out of the transaction device,and may determine whether a response, indicating that the notificationwas received by the user and indicating a reason for utilizing the aborttransaction mechanism, is received from the user device within athreshold period of time. The verification platform may provide an alertmessage to an emergency point of contact for the user and/or to anemergency service when it is determined that the response is notreceived from the user device within the threshold period of time.

In this way, the verification platform assures a user of a transactiondevice that a transaction is concurrently canceled and the user loggedout of the transaction device whenever the user feels unsafe and/orcaptive. Furthermore, the verification platform conserves computingresources (e.g., processing resources, memory resources, and/or thelike) and network resources that would otherwise be wasted in performingthe multiple steps required to ensure that the transaction is canceled.For example, the verification platform conserves computing resourcesutilized by the transaction device to perform the additional stepsneeded to cancel the transaction, network resources utilized by thetransaction device to communicate with a backend system and cancel thetransaction, computing resources utilized by the backend system toperform the additional steps needed to cancel the transaction, and/orthe like.

FIGS. 1A-1F are diagrams of one or more example implementations 100described herein. As shown in FIG. 1A, a transaction device (e.g., witha camera) may be associated with a user, a user device, and averification platform. The user may log into the transaction device(e.g., with a transaction card and/or the user device) to conduct atransaction (e.g., a withdrawal, a deposit, a transfer, and/or the like)via the transaction device. As further shown, and by reference number105, the verification platform may receive transaction data associatedwith the transaction of the user logged into the transaction device. Insome implementations, the transaction data may include data identifyingthe user, an account associated with the user, the transaction beingconducted by the user, the transaction device, a location of thetransaction device, and/or the like. In some implementations, theverification platform may be associated with hundreds, thousands,millions, and/or the like of transaction devices, user devices, andusers and may receive transaction data from the transaction devices.

As shown in FIG. 1B, the transaction device may include a touchscreendisplay, a keypad, a camera, and/or the like. In some implementations,the transaction device may include a display device and keypad, atouchscreen display and no keypad, and/or one or more other components(e.g., a printer for printing a receipt, a slot for receiving atransaction card, and/or the like). In some implementations, thetouchscreen display may enable the user to input sensitive information(e.g., a personal identification number (PIN), a user identifier, and/orthe like), view sensitive information (e.g., an account number, anaccount balance, an image of a keypad, and/or the like), and/or thelike. In one example, the user may utilize the image of the keypad toinput a PIN of the user, to input an amount of money to withdraw, toselect an account from which to withdraw the money, and/or the like.

In some implementations, the keypad may include keys, with particularnumbers (e.g., 0 through 9), that may be used to enter a PIN of theuser, an enter key that may be used to enter or input the PIN providedby the user, a clear key that may be used to clear the PIN input by theuser, and/or the like. In some implementations, information input viathe keypad may be displayed via the touchscreen display or a displaydevice.

In some implementations, the camera may include an image capture device(e.g., a digital camera) that may be used to capture an image of theuser and surroundings of the user, a video capture device (e.g., a videocamera) that may be used to capture a video of the user and thesurroundings of the user, and/or the like.

As further shown in FIG. 1B, the touchscreen display and/or the keypadmay include a single selection abort transaction mechanism that, whenselected, enables the user to concurrently cancel a transaction and logout of the transaction device. In some implementations, the singleselection abort transaction mechanism may be displayed as a button or akey on the touchscreen display, may be a button or a key on the keypad,and/or the like. In some implementations, the single selection aborttransaction mechanism may be selected a single time by the user toconcurrently cancel the transaction and log out of the transactiondevice.

In some implementations, the user may select the single selection aborttransaction mechanism a single time (e.g., a single tap) to have atransaction card returned, may select the single selection aborttransaction mechanism two times (e.g., a double tap) to have atransaction card destroyed, and/or the like. In this way, if the userfeels unsafe, the user may double tap the single selection aborttransaction mechanism to have the transaction card destroyed and preventtheft of the transaction card. If the user feels safe but is just in ahurry (e.g., feels captive), the user may single tap the singleselection abort transaction mechanism, receive the transaction card, andleave the transaction device knowing that the transaction was canceledand that the user is logged out of the transaction device.

As shown in FIG. 1C, and by reference number 110, if the user selectsthe single selection abort transaction mechanism, the verificationplatform may receive, from the transaction device, informationindicating a selection of the single selection abort transactionmechanism (e.g., by the user) to cause the transaction to be canceledconcurrently with the user being logged out of the transaction device.In some implementations, the transaction device may concurrently cancelthe transaction and log the user out of the transaction device when theuser selects the single selection abort transaction mechanism. In suchimplementations, the transaction device may provide, to the verificationplatform, the information indicating the selection of the singleselection abort transaction mechanism to cause the transaction to becanceled concurrently with the user being logged out of the transactiondevice.

In some implementations, the verification platform may receive, from thetransaction device, information indicating the selection of the singleselection abort transaction mechanism. In such implementations, theverification platform may concurrently cancel the transaction and logthe user out of the transaction device based on the selection. Theverification platform may provide, to the transaction device,information indicating that the transaction was canceled concurrentlywith the user being logged out of the transaction device.

In some implementations, if the transaction device retains thetransaction card of the user during the transaction, selection of thesingle selection abort mechanism may cause a mechanical mechanism (e.g.,a mechanical release lever) of the transaction device to eject thetransaction card to the user. In some implementations, selection of thesingle selection abort mechanism may cause the transaction device toretain the transaction card with the mechanical mechanism, consume thetransaction card, destroy the transaction card, lock the transactiondevice (e.g., and remain locked until a representative of a financialinstitution associated with the transaction device unlocks thetransaction device), and/or the like.

As shown in FIG. 1D, and by reference number 115, the verificationplatform may provide, to the user device, a notification indicating thatthe transaction was canceled concurrently with the user being logged outof the transaction device. In some implementations, the notification maybe provided via an application, a short message service (SMS) or textmessage, an instant message, an email, a telephone call, and/or thelike. In some implementations, the notification may include a requestrequesting that the user indicate that the notification was received bythe user and requesting that the user indicate a reason for utilizingthe single selection abort transaction mechanism. The verificationplatform may use information identifying the reason for utilizing thesingle selection abort transaction mechanism to determine one or moresubsequent actions to perform, as example of which is described below inconnection with FIG. 1F. In this way, the user may be informed that thetransaction was canceled and that the user logged out of the transactiondevice, which may assure the user that credentials, the transactioncard, an account, and/or the like of the user will not be compromised.

As further shown in FIG. 1D, and by reference number 120, theverification platform may receive, from the user device and based on thenotification, a response indicating that the notification was receivedby the user and indicating a reason for utilizing the single selectionabort transaction mechanism. In some implementations, the reason forutilizing the single selection abort transaction mechanism may includeinformation indicating that the user aborted the transaction because theuser felt unsafe, information indicating that the user aborted thetransaction because the user was in a hurry (e.g., felt captive),information indicating that the user aborted the transaction due toanother reason, and/or the like.

In some implementations, when the verification platform provides thenotification to the user device, the verification platform may start atimer. As further shown in FIG. 1D, and by reference number 125, theverification platform may determine whether the response is receivedwithin a threshold period of time (e.g., in seconds, minutes, and/or thelike). In some implementations, the timer may be used by theverification platform to determine whether the response is receivedwithin the threshold period of time. In this way, the verificationplatform may determine whether the user is safe or requires emergencyassistance.

As further shown in FIG. 1D, and by reference number 130, theverification platform may provide an alert message (e.g., via a SMSmessage, an instant message, an email message, a telephone call, and/orthe like) to an emergency point of contact and/or to an emergencyservice (e.g., the police) when the response is not received within thethreshold period of time. In some implementations, the user may utilizea bank application to provide information identifying the emergencypoint of contact, and the verification platform may utilize suchinformation to provide the alert message to the emergency point ofcontact. In some implementations, the verification platform maydetermine a location of the user (e.g., based on a location of thetransaction device, the user device, and/or the like), and may identifyan emergency service that is closest to the location of the user. Thisway the emergency service may respond more quickly to the alert messageand assist the user.

In some implementations, the transaction device may capture video of thearea surrounding the transaction device when the response is notreceived within the threshold period of time. Emergency responders mayuse the captured video to assist the user (e.g., by identifying anindividual who was making the user feel unsafe).

As shown in FIG. 1E, the verification platform may receive aborttransaction data identifying the aborted transaction by the user,aborted transactions by other users of the transaction device, a reasonthe transaction was aborted by the user, reasons the other users abortedthe transactions, and/or the like. As further shown in FIG. 1E, and byreference number 135, the verification platform may process the aborttransaction data, with a machine learning model, to determine one ormore actions to perform. In some implementations, the machine learningmodel may include a pattern recognition model that generates predictionsfor one or more actions to perform based on abort transaction data. Insome implementations, the one or more actions that may be predicted bythe machine learning model are described below in connection with FIG.1F.

In some implementations, the verification platform may perform atraining operation on the machine learning model with historical aborttransaction data. The historical abort transaction data may include dataidentifying aborted transactions by users of the transaction device,data indicating that the users aborted the transactions because theyfelt unsafe at the transaction device, data indicating that the usersaborted the transactions because they were in a hurry, data indicatingthat the users aborted the transactions for other reasons, and/or thelike.

In some implementations, the verification platform may separate thehistorical abort transaction data into a training set, a validation set,a test set, and/or the like. The training set may be utilized to trainthe machine learning model. The validation set may be utilized tovalidate results generated based on training the machine learning modelwith the training set. The test set may be utilized to test resultsgenerated by the trained machine learning model.

In some implementations, the verification platform may train the machinelearning model using, for example, an unsupervised training procedureand based on the training set of the historical abort transaction data.For example, the verification platform may perform dimensionalityreduction to reduce the historical abort transaction data to a minimumfeature set, thereby reducing resources (e.g., processing resources,memory resources, and/or the like) to train the machine learning modeland may apply a classification technique to the minimum feature set.

In some implementations, the verification platform may use a logisticregression classification technique to determine a categorical outcome(e.g., that one or more actions should be performed based on thehistorical abort transaction data). Additionally, or alternatively, theverification platform may use a naïve Bayesian classifier technique. Inthis case, the verification platform may perform binary recursivepartitioning to split the historical abort transaction data intopartitions and/or branches and use the partitions and/or branches toperform predictions (e.g., that one or more actions should be performedbased on the historical abort transaction data). Based on usingrecursive partitioning, the verification platform may reduce utilizationof computing resources relative to manual, linear sorting and analysisof data points, thereby enabling use of thousands, millions, or billionsof data points to train the machine learning model, which may result ina more accurate model than using fewer data points.

Additionally, or alternatively, the verification platform may use asupport vector machine (SVM) classifier technique to generate anon-linear boundary between data points in the training set. In thiscase, the non-linear boundary is used to classify test data into aparticular class.

Additionally, or alternatively, the verification platform may train themachine learning model using a supervised training procedure thatincludes receiving input to the machine learning model from a subjectmatter expert, which may reduce an amount of time, an amount ofprocessing resources, and/or the like to train the machine learningmodel relative to an unsupervised training procedure. In someimplementations, the verification platform may use one or more othermodel training techniques, such as a neural network technique, a latentsemantic indexing technique, and/or the like. For example, theverification platform may perform an artificial neural networkprocessing technique (e.g., using a two-layer feedforward neural networkarchitecture, a three-layer feedforward neural network architecture,and/or the like) to perform pattern recognition with regard to optimalregions of the historical abort transaction data. In this case, usingthe artificial neural network processing technique may improve anaccuracy of the trained machine learning model generated by theverification platform by enabling the model to be more robust thanunprocessed models to noisy, imprecise, or incomplete data, and byenabling the verification platform to detect patterns and/or trendsundetectable to human analysts or systems using less complex techniques.

In some implementations, the verification platform may receive thetrained machine learning model from another source. In suchimplementations, the verification platform may utilize the trainedmachine learning model to process the abort transaction data and todetermine one or more actions to perform based on the abort transactiondata.

In this way, the verification platform may provide the abort transactiondata as an input to the machine learning model, and the machine learningmodel may output information indicating the one or more actions toperform based on the input.

As shown in FIG. 1F, and by reference number 140, the verificationplatform may perform the one or more actions. For example, the one ormore actions may include the verification platform causing a securityguard to be dispatched to a location of the transaction device. Here,the verification platform may send a message (e.g., a text message) orplace a telephone call to a device of the security guard or a device ofa command center to cause the security guard to be dispatched to thelocation. In this way, the verification platform improves the safety ofusers of the transaction device and ensures that the users that theywill feel safe. This may reduce utilization of the single selectionabort mechanism at the transaction device, which may conserve computingresources and network resources.

In some implementations, the one or more actions may include theverification platform causing additional cameras to be installed at thelocation of the transaction device. For example, the verificationplatform may identify a local security company (e.g., via an Internetsearch) and cause a purchase/work order to be submitted to the localsecurity company for the additional camera installation. In this way,the verification platform improves the safety of users of thetransaction device and ensures that the users that they will feel safe.This may reduce utilization of the single selection abort mechanism atthe transaction device, which may conserve computing resources andnetwork resources.

In some implementations, the one or more actions may include theverification platform causing the transaction device to be relocated toa different location. For example, the verification platform mayidentify a local company (e.g., via an Internet search) and cause a workorder to be submitted to the local company for the transaction devicerelocation. In this way, the verification platform may provide a saferlocation for the transaction device, which may reduce utilization of thesingle selection abort mechanism at the transaction device and conservecomputing resources and network resources.

In some implementations, the one or more actions may include theverification platform causing a locking mechanism to be installed at thelocation of the transaction device. For example, a door to thetransaction device may be locked and opened only by users with theirtransaction cards and/or with their user devices (e.g., via a bankapplication on their user devices). In this example, the verificationplatform may identify a local security company (e.g., via an Internetsearch) and cause a purchase/work order to be submitted to the localsecurity company for the lock installation. In this way, theverification platform improves the safety of users of the transactiondevice and ensures that the users that they will feel safe. This mayreduce utilization of the single selection abort mechanism at thetransaction device, which may conserve computing resources and networkresources.

In some implementations, the one or more actions may include theverification platform causing a camera at the location of thetransaction device (e.g., the camera provided with the transactiondevice) to be monitored. In some implementations, the verificationplatform may receive camera data from the camera monitoring the locationof the transaction device and may predict the reason for utilizing thesingle selection abort transaction mechanism based on the camera data.In this way, the verification platform may determine whether the user isin danger and may dispatch emergency personnel when the user is indanger.

In some implementations, the one or more actions may include theverification platform requesting information identifying an emergencypoint of contact from the user. For example, the verification platformmay request the information identifying the emergency point of contactwhen the user failed to provide such information. In this way, theverification platform may obtain an emergency point of contact that maybe utilized when the user does not respond to the notification from theverification platform.

In some implementations, the one or more actions may include theverification platform requesting further details about an abortedtransaction from the user. In this way, the verification platform mayreceive additional information about the aborted transaction, which maybe utilized to improve the machine learning model, to enhance the safetyof the user, and/or the like.

The above actions are provided merely by way of example. Theverification platform may perform additional or different actions thanthose described above. For example, in some implementations, theverification platform may cause the transaction device to be temporarilylocked, so as not to allow subsequent transactions to be performed atthe transaction device. This action may be beneficial in situationswhere the user who aborted the transaction indicated that the reason foraborting the transaction is that a suspicious individual was lurkingaround the transaction device. In some implementations, the verificationplatform may cause the transaction device to display a message, such as“out of order.” In this way, the verification platform may notify otherusers not to use this particular transaction device.

In some implementations, the one or more actions may include theverification platform determining that the user aborted the transactionbecause the user was in a hurry (e.g., but felt safe), and providing, tothe user device, a notification indicating that the transaction wascanceled and the user logged out of the transaction device. In suchimplementations, the verification platform may not require the user toacknowledge receipt of the notification and may not provide messages toan emergency point of contact and/or an emergency service since the userwas self and just in a hurry. The verification platform may utilize themachine learning model to determine (e.g., from a camera feed associatedwith the transaction device and/or from previous user interactions withtransaction devices) that the user is not in danger. Therefore, theverification platform may not require acknowledgement of thenotification and may not alert the emergency point of contact and/or theemergency service.

In this way, several different stages of the process for performingactions based on selection of a single selection abort transactionmechanism may be automated with a machine learning model, which mayconserve computing resources (e.g., processing resources, memoryresources, and/or the like). Furthermore, implementations describedherein use a rigorous, computerized process to perform tasks or rolesthat were not previously performed. For example, currently there doesnot exist a technique that utilizes a single selection abort transactionmechanism or a machine learning model to perform actions based onselection of the single selection abort transaction mechanism. Further,the process for performing actions based on selection of a singleselection abort transaction mechanism conserves computing resources(e.g., processing resources, memory resources, and/or the like) thatwould otherwise be wasted in performing multiple steps required toensure that a transaction is canceled.

As indicated above, FIGS. 1A-1F are provided merely as examples. Otherexamples may differ from what is described with regard to FIGS. 1A-1F.

FIG. 2 is a diagram of an example environment 200 in which systemsand/or methods, described herein, may be implemented. As shown in FIG. 2, environment 200 may include a transaction device 210, a verificationplatform 220, a network 230, and a user device 240. Devices ofenvironment 200 may interconnect via wired connections, wirelessconnections, or a combination of wired and wireless connections.

Transaction device 210 includes one or more devices capable ofreceiving, generating, storing, processing, and/or providinginformation, such as information described herein. For example,transaction device 210 may include an automated teller machine (ATM)device, a point of sale (POS) device, a kiosk device, and/or the like.

The ATM device may include an electronic telecommunications device thatenables customers of financial institutions to perform financialtransactions, such as cash withdrawals, deposits, transferring funds,obtaining account information, and/or the like, at any time and withoutdirect interaction with employees of the financial institutions. The POSdevice may include an electronic device used to process transaction cardpayments at retail locations. The POS device may read information from atransaction card (e.g., a credit card, a debit card, a gift card, and/orthe like), and may determine whether there are sufficient funds in anaccount associated with the transaction card for a transaction. The POSdevice may transfer funds from the account associated with thetransaction card to an account of a retailer and may record thetransaction. The kiosk device may include a computer terminal featuringspecialized hardware and/or software that provides access to informationand/or applications for communication, commerce, entertainment,education, and/or the like.

In some implementations, transaction device 210 may include an inputelement (e.g., a keypad, a keyboard, a touchscreen display, and/or thelike) for receiving input data from a user of the transaction device. Insome implementations, transaction device 210 may include more than oneinput element (e.g., a keypad and a touchscreen display). Additionally,or alternatively, transaction device 210 may include one or moresensors, such as a camera.

Verification platform 220 includes one or more devices that may utilizea machine learning model to perform actions based on selection of asingle selection abort transaction mechanism. In some implementations,verification platform 220 may be modular such that certain softwarecomponents may be swapped in or out depending on a particular need. Assuch, verification platform 220 may be easily and/or quicklyreconfigured for different uses. In some implementations, verificationplatform 220 may receive information from and/or transmit information toone or more transaction devices 210 and/or user devices 240.

In some implementations, as shown, verification platform 220 may behosted in a cloud computing environment 222. Notably, whileimplementations described herein describe verification platform 220 asbeing hosted in cloud computing environment 222, in someimplementations, verification platform 220 may be non-cloud-based (i.e.,may be implemented outside of a cloud computing environment) or may bepartially cloud-based.

Cloud computing environment 222 includes an environment that may hostverification platform 220. Cloud computing environment 222 may providecomputation, software, data access, storage, etc. services that do notrequire end-user knowledge of a physical location and configuration ofsystem(s) and/or device(s) that host verification platform 220. Asshown, cloud computing environment 222 may include a group of computingresources 224 (referred to collectively as “computing resources 224” andindividually as “computing resource 224”).

Computing resource 224 includes one or more personal computers,workstation computers, server devices, or other types of computationand/or communication devices. In some implementations, computingresource 224 may host verification platform 220. The cloud resources mayinclude compute instances executing in computing resource 224, storagedevices provided in computing resource 224, data transfer devicesprovided by computing resource 224, etc. In some implementations,computing resource 224 may communicate with other computing resources224 via wired connections, wireless connections, or a combination ofwired and wireless connections.

As further shown in FIG. 2 , computing resource 224 includes a group ofcloud resources, such as one or more applications (“APPs”) 224-1, one ormore virtual machines (“VMs”) 224-2, virtualized storage (“VSs”) 224-3,one or more hypervisors (“HYPs”) 224-4, and/or the like.

Application 224-1 includes one or more software applications that may beprovided to or accessed by transaction device 210 and/or user device240. Application 224-1 may eliminate a need to install and execute thesoftware applications on transaction device 210 and/or user device 240.For example, application 224-1 may include software associated withverification platform 220 and/or any other software capable of beingprovided via cloud computing environment 222. In some implementations,one application 224-1 may send/receive information to/from one or moreother applications 224-1, via virtual machine 224-2.

Virtual machine 224-2 includes a software implementation of a machine(e.g., a computer) that executes programs like a physical machine.Virtual machine 224-2 may be either a system virtual machine or aprocess virtual machine, depending upon use and degree of correspondenceto any real machine by virtual machine 224-2. A system virtual machinemay provide a complete system platform that supports execution of acomplete operating system (“OS”). A process virtual machine may executea single program and may support a single process. In someimplementations, virtual machine 224-2 may execute on behalf of a user(e.g., a user of transaction device 210 and/or user device 240 or anoperator of verification platform 220), and may manage infrastructure ofcloud computing environment 222, such as data management,synchronization, or long-duration data transfers.

Virtualized storage 224-3 includes one or more storage systems and/orone or more devices that use virtualization techniques within thestorage systems or devices of computing resource 224. In someimplementations, within the context of a storage system, types ofvirtualizations may include block virtualization and filevirtualization. Block virtualization may refer to abstraction (orseparation) of logical storage from physical storage so that the storagesystem may be accessed without regard to physical storage orheterogeneous structure. The separation may provide administrators ofthe storage system with flexibility in how the administrators managestorage for end users. File virtualization may eliminate dependenciesbetween data accessed at a file level and a location where files arephysically stored. This may enable optimization of storage use, serverconsolidation, and/or performance of non-disruptive file migrations.

Hypervisor 224-4 may provide hardware virtualization techniques thatallow multiple operating systems (e.g., “guest operating systems”) toexecute concurrently on a host computer, such as computing resource 224.Hypervisor 224-4 may present a virtual operating platform to the guestoperating systems and may manage the execution of the guest operatingsystems. Multiple instances of a variety of operating systems may sharevirtualized hardware resources.

Network 230 includes one or more wired and/or wireless networks. Forexample, network 230 may include a cellular network (e.g., a fifthgeneration (5G) network, a long-term evolution (LTE) network, a thirdgeneration (3G) network, a code division multiple access (CDMA) network,etc.), a public land mobile network (PLMN), a local area network (LAN),a wide area network (WAN), a metropolitan area network (MAN), atelephone network (e.g., the Public Switched Telephone Network (PSTN)),a private network, an ad hoc network, an intranet, the Internet, a fiberoptic-based network, and/or the like, and/or a combination of these orother types of networks.

User device 240 includes one or more devices capable of receiving,generating, storing, processing, and/or providing information, such asinformation described herein. For example, user device 240 may include amobile phone (e.g., a smart phone, a radiotelephone, etc.), a laptopcomputer, a tablet computer, a desktop computer, a handheld computer, agaming device, a wearable communication device (e.g., a smartwristwatch, a pair of smart eyeglasses, etc.), or a similar type ofdevice. In some implementations, user device 240 may receive informationfrom and/or transmit information to transaction device 210 and/orverification platform 220.

The number and arrangement of devices and networks shown in FIG. 2 areprovided as an example. In practice, there may be additional devicesand/or networks, fewer devices and/or networks, different devices and/ornetworks, or differently arranged devices and/or networks than thoseshown in FIG. 2 . Furthermore, two or more devices shown in FIG. 2 maybe implemented within a single device and/or a single device shown inFIG. 2 may be implemented as multiple, distributed devices.Additionally, or alternatively, a set of devices (e.g., one or moredevices) of environment 200 may perform one or more functions describedas being performed by another set of devices of environment 200.

FIG. 3 is a diagram of example components of a device 300. Device 300may correspond to transaction device 210, verification platform 220,computing resource 224, and/or user device 240. In some implementations,transaction device 210, verification platform 220, computing resource224, and/or user device 240 may include one or more devices 300 and/orone or more components of device 300. As shown in FIG. 3 , device 300may include a bus 310, a processor 320, a memory 330, a storagecomponent 340, an input component 350, an output component 360, and/or acommunication interface 370.

Bus 310 includes a component that permits communication among thecomponents of device 300. Processor 320 is implemented in hardware,firmware, or a combination of hardware and software. Processor 320 is acentral processing unit (CPU), a graphics processing unit (GPU), anaccelerated processing unit (APU), a microprocessor, a microcontroller,a digital signal processor (DSP), a field-programmable gate array(FPGA), an application-specific integrated circuit (ASIC), or anothertype of processing component. In some implementations, processor 320includes one or more processors capable of being programmed to perform afunction. Memory 330 includes a random-access memory (RAM), a read onlymemory (ROM), and/or another type of dynamic or static storage device(e.g., a flash memory, a magnetic memory, and/or an optical memory) thatstores information and/or instructions for use by processor 320.

Storage component 340 stores information and/or software related to theoperation and use of device 300. For example, storage component 340 mayinclude a hard disk (e.g., a magnetic disk, an optical disk, amagneto-optic disk, and/or a solid-state disk), a compact disc (CD), adigital versatile disc (DVD), a floppy disk, a cartridge, a magnetictape, and/or another type of non-transitory computer-readable medium,along with a corresponding drive.

Input component 350 includes a component that permits device 300 toreceive information, such as via user input (e.g., a touch screendisplay, a keyboard, a keypad, a mouse, a button, a switch, and/or amicrophone). Additionally, or alternatively, input component 350 mayinclude a sensor for sensing information (e.g., a global positioningsystem (GPS) component, an accelerometer, a gyroscope, and/or anactuator). Output component 360 includes a component that providesoutput information from device 300 (e.g., a display, a speaker, and/orone or more light-emitting diodes (LEDs)).

Communication interface 370 includes a transceiver-like component (e.g.,a transceiver and/or a separate receiver and transmitter) that enablesdevice 300 to communicate with other devices, such as via a wiredconnection, a wireless connection, or a combination of wired andwireless connections. Communication interface 370 may permit device 300to receive information from another device and/or provide information toanother device. For example, communication interface 370 may include anEthernet interface, an optical interface, a coaxial interface, aninfrared interface, a radio frequency (RF) interface, a universal serialbus (USB) interface, a Wi-Fi interface, a cellular network interface,and/or the like.

Device 300 may perform one or more processes described herein. Device300 may perform these processes based on processor 320 executingsoftware instructions stored by a non-transitory computer-readablemedium, such as memory 330 and/or storage component 340. Acomputer-readable medium is defined herein as a non-transitory memorydevice. A memory device includes memory space within a single physicalstorage device or memory space spread across multiple physical storagedevices.

Software instructions may be read into memory 330 and/or storagecomponent 340 from another computer-readable medium or from anotherdevice via communication interface 370. When executed, softwareinstructions stored in memory 330 and/or storage component 340 may causeprocessor 320 to perform one or more processes described herein.Additionally, or alternatively, hardwired circuitry may be used in placeof or in combination with software instructions to perform one or moreprocesses described herein. Thus, implementations described herein arenot limited to any specific combination of hardware circuitry andsoftware.

The number and arrangement of components shown in FIG. 3 are provided asan example. In practice, device 300 may include additional components,fewer components, different components, or differently arrangedcomponents than those shown in FIG. 3 . Additionally, or alternatively,a set of components (e.g., one or more components) of device 300 mayperform one or more functions described as being performed by anotherset of components of device 300.

FIG. 4 is a flow chart of an example process 400 for utilizing a machinelearning model to perform actions based on selection of a singleselection abort transaction mechanism. In some implementations, one ormore process blocks of FIG. 4 may be performed by a verificationplatform (e.g., verification platform 220). In some implementations, oneor more process blocks of FIG. 4 may be performed by another device or agroup of devices separate from or including the verification platform,such as a transaction device (e.g., transaction device 210) and/or auser device (e.g., user device 240).

As shown in FIG. 4 , process 400 may include receiving, from atransaction device, transaction data associated with a transaction of auser logged into the transaction device, the transaction deviceincluding an abort transaction mechanism that, when selected, enablesthe user to concurrently cancel the transaction and log out of thetransaction device (block 410). For example, the verification platform(e.g., using computing resource 224, processor 320, communicationinterface 370, and/or the like) may receive, from a transaction device,transaction data associated with a transaction of a user logged into thetransaction device, as described above in connection with FIGS. 1A-2 .In some implementations, the transaction device may include an aborttransaction mechanism that, when selected, enables the user toconcurrently cancel the transaction and log out of the transactiondevice.

As further shown in FIG. 4 , process 400 may include receivinginformation indicating a selection of the abort transaction mechanismfrom the transaction device to cause the transaction to be canceledconcurrently with the user being logged out of the transaction device(block 420). For example, the verification platform (e.g., usingcomputing resource 224, processor 320, communication interface 370,and/or the like) may receive information indicating a selection of theabort transaction mechanism from the transaction device to cause thetransaction to be canceled concurrently with the user being logged outof the transaction device, as described above in connection with FIGS.1A-2 .

As further shown in FIG. 4 , process 400 may include providing, to auser device associated with the user, and based on receiving theinformation indicating the selection of the abort transaction mechanism,a notification indicating that the transaction was canceled and that theuser was logged out of the transaction device (block 430). For example,the verification platform (e.g., using computing resource 224, processor320, storage component 340, communication interface 370, and/or thelike) may provide, to a user device associated with the user, and basedon receiving the information indicating the selection of the aborttransaction mechanism, a notification indicating that the transactionwas canceled and that the user was logged out of the transaction device,as described above in connection with FIGS. 1A-2 .

As further shown in FIG. 4 , process 400 may include determining whethera response, indicating that the notification was received by the userand indicating a reason for utilizing the abort transaction mechanism,is received from the user device within a threshold period of time(block 440). For example, the verification platform (e.g., usingcomputing resource 224, processor 320, memory 330, and/or the like) maydetermine whether a response, indicating that the notification wasreceived by the user and indicating a reason for utilizing the aborttransaction mechanism, is received from the user device within athreshold period of time, as described above in connection with FIGS.1A-2 .

As further shown in FIG. 4 , process 400 may include providing an alertmessage to an emergency point of contact for the user and/or to anemergency service when it is determined that the response is notreceived from the user device within the threshold period of time (block450). For example, the verification platform (e.g., using computingresource 224, processor 320, memory 330, communication interface 370,and/or the like) may provide an alert message to an emergency point ofcontact for the user and/or to an emergency service when it isdetermined that the response is not received from the user device withinthe threshold period of time, as described above in connection withFIGS. 1A-2 .

Process 400 may include additional implementations, such as any singleimplementation or any combination of implementations described belowand/or described with regard to any other process described herein.

In some implementations, the verification platform may processinformation identifying the reason for utilizing the abort transactionmechanism, with a machine learning model, to determine one or moreactions to perform, and may perform the one or more actions.

In some implementations, when performing the one or more actions, theverification platform may cause a security guard to be provided at alocation of the transaction device, may cause a camera at the locationof the transaction device to be monitored, may cause an additionalcamera to be installed at the location of the transaction device, maycause the transaction device to be relocated to a different locationfrom the location of the transaction device, may cause a lockingmechanism to be installed at the location of the transaction device, mayrequest information identifying the emergency point of contact from theuser device, and/or may request further details about the transactionfrom the user device.

In some implementations, information identifying the reason forutilizing the abort transaction mechanism may include informationindicating that the user aborted the transaction because the user feltunsafe, and/or information indicating that the user aborted thetransaction because the user was in a hurry.

In some implementations, the transaction device may include a mechanicalmechanism to retain a transaction card of the user during thetransaction, and the verification platform may cause the mechanicalmechanism to release the transaction card based on the selection of theabort transaction mechanism, where the transaction is canceledconcurrently with the user being logged out of the transaction deviceafter causing the mechanical mechanism to release the transaction card.

In some implementations, the transaction device may include a mechanicalmechanism to retain or destroy a transaction card of the user during thetransaction, and the verification platform may cause the mechanicalmechanism to retain or destroy the transaction card based on theselection of the abort transaction mechanism. In some implementations,the verification platform may cause a camera, located at a location ofthe transaction device, to capture images and/or video of the location,based on the selection of the abort transaction mechanism.

Although FIG. 4 shows example blocks of process 400, in someimplementations, process 400 may include additional blocks, fewerblocks, different blocks, or differently arranged blocks than thosedepicted in FIG. 4 . Additionally, or alternatively, two or more of theblocks of process 400 may be performed in parallel.

FIG. 5 is a flow chart of an example process 500 for utilizing a machinelearning model to perform actions based on selection of a singleselection abort transaction mechanism. In some implementations, one ormore process blocks of FIG. 5 may be performed by a verificationplatform (e.g., verification platform 220). In some implementations, oneor more process blocks of FIG. 5 may be performed by another device or agroup of devices separate from or including the verification platform,such as a transaction device (e.g., transaction device 210) and/or auser device (e.g., user device 240).

As shown in FIG. 5 , process 500 may include receiving, from atransaction device, transaction data associated with a transaction of auser logged into the transaction device, the transaction deviceincluding an abort transaction mechanism that, when selected a singletime, causes the transaction to be canceled and the user to be loggedout of the transaction device (block 510). For example, the verificationplatform (e.g., using computing resource 224, processor 320,communication interface 370, and/or the like) may receive, from atransaction device, transaction data associated with a transaction of auser logged into the transaction device, as described above inconnection with FIGS. 1A-2 . In some implementations, the transactiondevice may include an abort transaction mechanism that, when selected asingle time, causes the transaction to be canceled and the user to belogged out of the transaction device.

As further shown in FIG. 5 , process 500 may include receivinginformation indicating a selection of the abort transaction mechanismfrom the transaction device to cause the transaction to be canceled andthe user to be logged out of the transaction device (block 520). Forexample, the verification platform (e.g., using computing resource 224,processor 320, communication interface 370, and/or the like) may receiveinformation indicating a selection of the abort transaction mechanismfrom the transaction device to cause the transaction to be canceled andthe user to be logged out of the transaction device, as described abovein connection with FIGS. 1A-2 .

As further shown in FIG. 5 , process 500 may include causing a camera ata location of the transaction device to be monitored based on receivingthe information indicating the selection of the abort transactionmechanism (block 530). For example, the verification platform (e.g.,using computing resource 224, processor 320, memory 330, communicationinterface 370, and/or the like) may cause a camera at a location of thetransaction device to be monitored based on receiving the informationindicating the selection of the abort transaction mechanism, asdescribed above in connection with FIGS. 1A-2 .

As further shown in FIG. 5 , process 500 may include providing, to auser device associated with the user, a notification indicating that thetransaction was canceled and that the user was logged out of thetransaction device (block 540). For example, the verification platform(e.g., using computing resource 224, processor 320, communicationinterface 370, and/or the like) may provide, to a user device associatedwith the user, a notification indicating that the transaction wascanceled and that the user was logged out of the transaction device, asdescribed above in connection with FIGS. 1A-2 .

As further shown in FIG. 5 , process 500 may include determining whethera response to the notification is received from the user device, whereinthe response is to indicate that the notification was received by theuser and indicate a reason for utilizing the abort transaction mechanism(block 550). For example, the verification platform (e.g., usingcomputing resource 224, processor 320, memory 330, and/or the like) maydetermine whether a response to the notification is received from theuser device, as described above in connection with FIGS. 1A-2 . In someimplementations, the response is to indicate that the notification wasreceived by the user and indicate a reason for utilizing the aborttransaction mechanism.

As further shown in FIG. 5 , process 500 may include selectivelyproviding an alert message to an emergency point of contact for the userand/or to an emergency service based on whether the response to thenotification is received from the user device, wherein the alert messageis to be provided when the response is not received from the userdevice, or wherein the alert message is not to be provided when theresponse is received from the user device or when camera data from thecamera indicates that the user is safe (block 560). For example, theverification platform (e.g., using computing resource 224, processor320, storage component 340, communication interface 370, and/or thelike) may selectively provide an alert message to an emergency point ofcontact for the user and/or to an emergency service based on whether theresponse to the notification is received from the user device, asdescribed above in connection with FIGS. 1A-2 . In some implementations,the alert message is to be provided when the response is not receivedfrom the user device. In some implementations, the alert message is notto be provided when the response is received from the user device orwhen camera data from the camera indicates that the user is safe.

Process 500 may include additional implementations, such as any singleimplementation or any combination of implementations described belowand/or described with regard to any other process described herein.

In some implementations, the verification platform may processinformation identifying the reason for utilizing the abort transactionmechanism and information identifying reasons for utilizing the aborttransaction mechanism by other users of the transaction device, with amachine learning model, to determine one or more actions to perform, andmay perform the one or more actions.

In some implementations, when performing the one or more actions, theverification platform may cause a security guard to be provided at thelocation of the transaction device, may cause an additional camera to beinstalled at the location of the transaction device, may cause thetransaction device to be relocated to a different location from thelocation of the transaction device, and/or may cause a locking mechanismto be installed at the location of the transaction device.

In some implementations, the verification platform may receive cameradata from the camera monitoring the location of the transaction device,and may predict the reason for utilizing the abort transaction mechanismbased on the camera data. In some implementations, the verificationplatform may cause the transaction device to release a transaction cardassociated with the user based on the selection of the abort transactionmechanism, and the transaction card may be released by the transactiondevice before the transaction is canceled and the user is logged out ofthe transaction device.

In some implementations, the verification platform may cause thetransaction device to destroy a transaction card associated with theuser based on the selection of the abort transaction mechanism. In someimplementations, information identifying the reason for utilizing theabort transaction mechanism may include information indicating that theuser aborted the transaction because the user felt unsafe, orinformation indicating that the user aborted the transaction because theuser was in a hurry.

Although FIG. 5 shows example blocks of process 500, in someimplementations, process 500 may include additional blocks, fewerblocks, different blocks, or differently arranged blocks than thosedepicted in FIG. 5 . Additionally, or alternatively, two or more of theblocks of process 500 may be performed in parallel.

FIG. 6 is a flow chart of an example process 600 for utilizing a machinelearning model to perform actions based on selection of a singleselection abort transaction mechanism. In some implementations, one ormore process blocks of FIG. 6 may be performed by a verificationplatform (e.g., verification platform 220). In some implementations, oneor more process blocks of FIG. 6 may be performed by another device or agroup of devices separate from or including the verification platform,such as a transaction device (e.g., transaction device 210) and/or auser device (e.g., user device 240).

As shown in FIG. 6 , process 600 may include receiving, from atransaction device, transaction data associated with a transaction of auser logged into the transaction device, the transaction deviceincluding an abort transaction mechanism that, when selected, enablesthe user to cancel the transaction and log out of the transaction deviceat a same time (block 610). For example, the verification platform(e.g., using computing resource 224, processor 320, communicationinterface 370, and/or the like) may receive, from a transaction device,transaction data associated with a transaction of a user logged into thetransaction device, as described above in connection with FIGS. 1A-2 .In some implementations, the transaction device may include an aborttransaction mechanism that, when selected, enables the user to cancelthe transaction and log out of the transaction device at a same time.

As further shown in FIG. 6 , process 600 may include receivinginformation indicating a selection of the abort transaction mechanismfrom the transaction device to cause the transaction to be canceled andthe user being logged out of the transaction device at the same time(block 620). For example, the verification platform (e.g., usingcomputing resource 224, processor 320, communication interface 370,and/or the like) may receive information indicating a selection of theabort transaction mechanism from the transaction device to cause thetransaction to be canceled and the user being logged out of thetransaction device at the same time, as described above in connectionwith FIGS. 1A-2 .

As further shown in FIG. 6 , process 600 may include providing, to auser device associated with the user and based on receiving theinformation indicating the selection of the abort transaction mechanism,a notification indicating that the transaction was canceled and that theuser was logged out of the transaction device (block 630). For example,the verification platform (e.g., using computing resource 224, processor320, storage component 340, communication interface 370, and/or thelike) may provide, to a user device associated with the user and basedon receiving the information indicating the selection of the aborttransaction mechanism, a notification indicating that the transactionwas canceled and that the user was logged out of the transaction device,as described above in connection with FIGS. 1A-2 .

As further shown in FIG. 6 , process 600 may include determining whethera response to the notification is received from the user device within athreshold period of time, the response indicating that the notificationwas received by the user and indicating a reason for utilizing the aborttransaction mechanism (block 640). For example, the verificationplatform (e.g., using computing resource 224, processor 320, memory 330,communication interface 370, and/or the like) may determine whether aresponse to the notification is received from the user device within athreshold period of time, as described above in connection with FIGS.1A-2 . In some implementations, the response may indicate that thenotification was received by the user and may indicate a reason forutilizing the abort transaction mechanism.

As further shown in FIG. 6 , process 600 may include selectivelyproviding an alert message to an emergency point of contact for the userand/or to an emergency service based on whether the response to thenotification is received from the user device within the thresholdperiod of time, the alert message is to be provided when the response isnot received from the user device, or the alert message is not to beprovided when the response is received from the user device (block 650).For example, the verification platform (e.g., using computing resource224, processor 320, memory 330, communication interface 370, and/or thelike) may selectively provide an alert message to an emergency point ofcontact for the user and/or to an emergency service based on whether theresponse to the notification is received from the user device within thethreshold period of time, as described above in connection with FIGS.1A-2 . In some implementations, the alert message is to be provided whenthe response is not received from the user device. In someimplementations, the alert message is not to be provided when theresponse is received from the user device.

Process 600 may include additional implementations, such as any singleimplementation or any combination of implementations described belowand/or described with regard to any other process described herein.

In some implementations, the verification platform may processinformation identifying the reason for utilizing the abort transactionmechanism, with a machine learning model, to determine whether thereason is a first reason or a second reason, may determine whether toperform a first action or a second action based on whether the reason isthe first reason or the second reason, where the first action isdifferent from the second action, and may selectively perform the firstaction or the second action.

In some implementations, information identifying the reason forutilizing the abort transaction mechanism includes informationindicating that the user aborted the transaction because the user feltunsafe, or information indicating that the user aborted the transactionbecause the user was in a hurry. In some implementations, theverification platform may cause the transaction device to release atransaction card associated with the user based on the selection of theabort transaction mechanism.

In some implementations, the verification platform may cause thetransaction device to retain or destroy a transaction card associatedwith the user based on the selection of the abort transaction mechanism.In some implementations, the verification platform may cause a camera,located at a location of the transaction device, to capture imagesand/or video of the location based on the selection of the aborttransaction mechanism, and may predict the reason for utilizing theabort transaction mechanism based on the images and/or the video of thelocation.

Although FIG. 6 shows example blocks of process 600, in someimplementations, process 600 may include additional blocks, fewerblocks, different blocks, or differently arranged blocks than thosedepicted in FIG. 6 . Additionally, or alternatively, two or more of theblocks of process 600 may be performed in parallel.

The foregoing disclosure provides illustration and description, but isnot intended to be exhaustive or to limit the implementations to theprecise forms disclosed. Modifications and variations may be made inlight of the above disclosure or may be acquired from practice of theimplementations.

As used herein, the term “component” is intended to be broadly construedas hardware, firmware, and/or a combination of hardware and software.

Certain user interfaces have been described herein and/or shown in thefigures. A user interface may include a graphical user interface, anon-graphical user interface, a text-based user interface, or the like.A user interface may provide information for display. In someimplementations, a user may interact with the information, such as byproviding input via an input component of a device that provides theuser interface for display. In some implementations, a user interfacemay be configurable by a device and/or a user (e.g., a user may changethe size of the user interface, information provided via the userinterface, a position of information provided via the user interface,etc.). Additionally, or alternatively, a user interface may bepre-configured to a standard configuration, a specific configurationbased on a type of device on which the user interface is displayed,and/or a set of configurations based on capabilities and/orspecifications associated with a device on which the user interface isdisplayed.

It will be apparent that systems and/or methods, described herein, maybe implemented in different forms of hardware, firmware, or acombination of hardware and software. The actual specialized controlhardware or software code used to implement these systems and/or methodsis not limiting of the implementations. Thus, the operation and behaviorof the systems and/or methods were described herein without reference tospecific software code—it being understood that software and hardwaremay be designed to implement the systems and/or methods based on thedescription herein.

Even though particular combinations of features are recited in theclaims and/or disclosed in the specification, these combinations are notintended to limit the disclosure of various implementations. In fact,many of these features may be combined in ways not specifically recitedin the claims and/or disclosed in the specification. Although eachdependent claim listed below may directly depend on only one claim, thedisclosure of various implementations includes each dependent claim incombination with every other claim in the claim set.

No element, act, or instruction used herein should be construed ascritical or essential unless explicitly described as such. Also, as usedherein, the articles “a” and “an” are intended to include one or moreitems, and may be used interchangeably with “one or more.” Furthermore,as used herein, the term “set” is intended to include one or more items(e.g., related items, unrelated items, a combination of related andunrelated items, etc.), and may be used interchangeably with “one ormore.” Where only one item is intended, the term “only one” or similarlanguage is used. Also, as used herein, the terms “has,” “have,”“having,” or the like are intended to be open-ended terms. Further, thephrase “based on” is intended to mean “based, at least in part, on”unless explicitly stated otherwise.

What is claimed is:
 1. A method, comprising: obtaining, by a transactiondevice, information indicating a selection of an abort transactionmechanism of the transaction device that, when selected, causes atransaction to be canceled and a user to be logged out of thetransaction device; sending, by the transaction device, transaction dataassociated with the transaction and including the information indicatingthe selection of the abort transaction mechanism; and disabling, by thetransaction device, an operation of the transaction device based onsending the transaction data.
 2. The method of claim 1, furthercomprising: displaying a message on the transaction device.
 3. Themethod of claim 1, wherein disabling the operation of the transactiondevice comprises: temporarily locking the transaction device fromperforming transactions.
 4. The method of claim 1, where the aborttransaction mechanism is displayed as a button or key on a touchscreendisplay of the transaction device.
 5. The method of claim 1, where theabort transaction mechanism is displayed as a button or key on a keypadof the transaction device.
 6. The method of claim 1, further comprising:destroying a card inserted into the transaction device based on theinformation indicating the selection of the abort transaction mechanism.7. The method of claim 1, wherein the transaction device is configuredto perform different actions based on how many times the aborttransaction mechanism was selected.
 8. A transaction device, comprising:one or more memories; and one or more processors, coupled to the one ormore memories, configured to: obtain information indicating a selectionof an abort transaction mechanism of the transaction device that, whenselected, causes a transaction to be canceled and a user to be loggedout of the transaction device; send transaction data associated with thetransaction and including the information indicating the selection ofthe abort transaction mechanism; and disable an operation of thetransaction device based on sending the transaction data.
 9. Thetransaction device of claim 8, wherein the one or more processors arefurther configured to: display a message on the transaction device. 10.The transaction device of claim 8, wherein the one or more processors,to disable the operation of the transaction device, are configured to:temporarily lock the transaction device from performing transactions.11. The transaction device of claim 8, where the abort transactionmechanism is displayed as a button or key on a touchscreen display ofthe transaction device.
 12. The transaction device of claim 8, where theabort transaction mechanism is displayed as a button or key on a keypadof the transaction device.
 13. The transaction device of claim 8,wherein the one or more processors are further configured to: destroy acard inserted into the transaction device based on the informationindicating the selection of the abort transaction mechanism.
 14. Thetransaction device of claim 8, wherein the transaction device isconfigured to perform different actions based on how many times theabort transaction mechanism was selected.
 15. A non-transitorycomputer-readable medium storing a set of instructions, the set ofinstructions comprising: one or more instructions that, when executed byone or more processors of a transaction device, cause the transactiondevice to: obtain information indicating a selection of an aborttransaction mechanism of the transaction device that, when selected,causes a transaction to be canceled and a user to be logged out of thetransaction device; send transaction data associated with thetransaction and including the information indicating the selection ofthe abort transaction mechanism; and disable an operation of thetransaction device based on sending the transaction data.
 16. Thenon-transitory computer-readable medium of claim 15, wherein the one ormore instructions, that cause the transaction device to disable theoperation of the transaction device, cause the transaction device to:temporarily lock the transaction device from performing transactions.17. The non-transitory computer-readable medium of claim 15, where theabort transaction mechanism is displayed as a button or key on atouchscreen display of the transaction device.
 18. The non-transitorycomputer-readable medium of claim 15, where the abort transactionmechanism is displayed as a button or key on a keypad of the transactiondevice.
 19. The non-transitory computer-readable medium of claim 15,wherein the one or more instructions further cause the transactiondevice to: destroy a card inserted into the transaction device based onthe information indicating the selection of the abort transactionmechanism.
 20. The non-transitory computer-readable medium of claim 15,wherein the one or more instructions further cause the transactiondevice to perform different actions based on how many times the aborttransaction mechanism was selected.